app/vmui: improve stream context modal#1439
Conversation
- warn and highlight logs with identical timestamps - show older logs above and newer logs below the target log - replace load control buttons with infinite scroll - expand stream_context time_window from 1m to 7d while loading context
Loori-R
added
the
web-ui
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found across 13 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> Signed-off-by: Yury Moladau <yurymolodov@gmail.com>
|
Should we keep the expanded logs state? When I load more logs, the expanded logs become closed. Screen.Recording.2026-05-22.at.11.25.41.mov |
| ...prev, | ||
| [dir]: data.length >= lines, | ||
| })); | ||
| if (data.length >= lines || isMaxTimeWindow(timeWindow)) { |
There was a problem hiding this comment.
As I observe it right now, the logic is the following:
- we always request N records until we get all N
- we keep requesting at the same timestamp but extending time_window until we get all N
This is simple logic and it works. But it has few downsides:
- In cases when there is a gap between log entries and we dont' get requests N logs - we will continue getting them with every time_window extension, over and over.
- This delays logs renderring as we might have to wait for multiple requests to complete until we get our N logs, while we already had some payload to render from previous requests
Here's a clip where request was repeating until it fit N entries
Screen.Recording.2026-05-22.at.09.50.59.mov
It would be nice to try to render some logs from that 2.7KiB received log entries, shift timestamp, extend time window and try new request from that position. And continue trying them until all N records were renderred.
There was a problem hiding this comment.
Updated. The loading now accumulates fetched logs, requests only the remaining count, and continues from the edge log of the previous response while expanding time_window.
There was a problem hiding this comment.
Thanks @Loori-R ! Is there a way to not wait for the all N to be collected, but spill out log entries as soon as they're available?
I am okay with collapsing the log entry on loading more logs. |
Co-authored-by: Roman Khavronenko <roman@victoriametrics.com> Signed-off-by: Yury Moladau <yurymolodov@gmail.com>
There was a problem hiding this comment.
1 issue found across 3 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Tip: cubic used a learning from your PR history. Let your coding agent read cubic learnings directly with the cubic MCP.
Fix all with cubic | Re-trigger cubic
Loori-R
force-pushed
the
vmui/stream-context-improvements
branch
from
52f5af4 to
dbdc187
Compare
3 participants
Describe Your Changes
Log contextmodal: previous logs are shown above the target log, next logs are shown below itLoad morecontrols and the logs-per-load selector with top/bottom infinite scrollstream_context time_window: start from1m, expand exponentially when fewer logs than requested are returned, and stop at7d. Related issue: app/vmui: allow configuringstream_contexttime_windowin Log Context #1397_timevalues, show a warning, and highlight their timestamp values